As used herein, the term “mobile code” refers to any portable executable instructions that can be downloaded and run on a computer system without modification or recompilation in a platform-independent fashion. Mobile code, especially Java mobile code, has gained widespread use in the areas of electronic commerce and services and will likely extend to many applications provided in future application service provider (ASP) environments.
Since the emergence of Java and related mobile code technologies, mobile code security has been a popular area for offerings of commercial solutions and active academic research. The use of mobile code presents a new challenge to the security systems in traditional platforms. Unlike shrink-wrapped, off-the-shelf application code, downloadable mobile code is inherently untrustworthy. Therefore, existing mobile code security solutions have focused on establishment of the trust between the application provider and the application user. A mobile code security solution is commonly considered sufficient if it can support the same level of trust between users and downloaded mobile code as its shrink-wrapped counterpart. All existing solutions share a common goal of protecting the principal's security domain from being compromised by untrustworthy downloaded code. As a result, existing systems use a set of security platforms designed for safe mobile code execution and run-time access control. Although these platforms work well in a traditional client-server system, they are not flexible enough in an application service provider (ASP) environment.
The rising trend of application outsourcing to ASPs disrupts the accepted application-usage model. Instead of owning the application after acquiring it from application providers, users outsource the runtime management and sometimes even the ownership of an application to an ASP. The user and the ASP are connected via a network, such as a global computer network like the Internet. In this new model, two different entities take on the roles of the runtime platform owner and the application user. This more complex environment complicates the mobile code security problem.
Existing systems use at least three common approaches to mobile code security: the sandbox approach, the code-signing approach, and the firewall approach. A fourth technique referred to as “proof-carrying code” is also used, though it is less-common. In the sandbox model, mobile code is given a run-time environment with a very limited set of system operations. The limited set of operations prevents mobile code from compromising the underlying platform, but it also limits the functionality of the mobile code. The firewall approach involves setting up a “mobile code firewall” device at the border of a security domain (e.g. the network boundary of an organization) to inspect mobile code.
The code-signing approach attempts to provide assurance about the source of the mobile code so it can be trusted. Microsoft Authenticode is an example of the code-signing technique. Mobile code is distributed in so-called Cabinet (.CAB) files. A typical Cabinet file contains the compressed mobile code and the signature of the mobile code generated using the application provider's private key. Before allowing the downloaded mobile code to run, users of the application examine the signature to ensure that (1) the code is properly signed by some application provider trusted by the user, and (2) the code has not be altered in transmission. In essence, signatures on mobile code work as the “digital shrink-wrap.” Code-signing is limiting in that it gives the application user only a binary choice of either completely trusting the code with the signature or denying its execution. There is no run-time access control support in a code-signing system.
The original Java security system is essentially a sandbox system. Downloaded Java applets are prevented access to many local system resources such as the file system and most of the network. Advances in Java security results in a hybrid system that combines the code-signing and sandbox approaches to create a run-time access control environment in which access-control decisions are made dynamically based on the signature of the code.
Security policies controlling access privileges to grant to particular mobile codes are stored in a local policy file editable only by the platform owner. Despite the additional flexibility, this hybrid approach is still limiting. First, run-time access control decisions are still based on who signs the code, not what the code will do. Second, a user of the application is assumed to be also the owner of, or at least in the same administration domain as, the run-time platform, which is not necessarily the case in the ASP environment. Lastly, mobile code instances are implicitly granted all the privileges permitted by the security policy regardless whether they are needed for the task in question, which is against the least privilege principle (LPP) of good security system practice. What is needed is a better system for managing mobile code in an ASP environment.